Lock nad IB recordom
Otázka od: Hlas
12. 9. 2002 22:43
Nad paradoxom, ked som dal record do stavu Edit bol locknuty - ziadny iny
uzivatel
nemohol tento zaznam editovat. Je nieco podobne mozne aj nad IB zaznamom?
Odpovedá: Zbysek Hlinka
12. 9. 2002 10:04
On 11 Sep 2002 at 21:04, Hlas wrote:
> Nad paradoxom, ked som dal record do stavu Edit bol locknuty - ziadny
> iny uzivatel nemohol tento zaznam editovat. Je nieco podobne mozne aj
> nad IB zaznamom?
Zamknout zaznam v IB neumim, anzto s IB nepracuji, ale chtel jsem
rict, ze k zamykani zaznamu v databazi musi byt opravdu zavazny
duvod. Zamykani jen tak pro tve pohodli neni dobra technika. Pokud
uzivatel zacne zaznam editovat, je pred poslanim zmeny zapotrebi
zkontrolovat, zda nedoslo k jeho zmene. A to se osetruje ulozenou
procedurou, takze zadne zamykani neni nutne. Pokud nejaka baba zacne
editovat, pak ji do toho zazvoni telefon, pak jde na zachod, obed, a
kdovi kam jeste, mas na problemy zadelano, pokud je zaznam zamceny.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Jan Sebelík
13. 9. 2002 3:39
Odesílatel: Hlas <hlas@inmail.sk>
Nad paradoxom, ked som dal record do stavu Edit bol locknuty - ziadny iny
uzivatel
nemohol tento zaznam editovat. Je nieco podobne mozne aj nad IB zaznamom?
Mozna me nekdo opravi, ale pokud se nemylim, tak to nejde.
IB ma tzv. "optimisticke transakce"
Zhruba receno zvitezi ten, kdo prvni ulozi (commit).
Druhemu je ohlasena chyba - to je treba osetrit.
(V IBX taky zalezi na typu transakce wait/nowait).
Jeste jina situace vznika pri pouziti TClientDataSet a ApplyUpdates.
Tam mi pri pokusu o update server posle na klienta zpatky konfliktni zaznam
spolu s jeho hodnotami puvodnimi, novymi a aktualnimi. Ja si pak mohu vybrat,
"kdo ma pravdu".
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================
Odpovedá: Erik Salaj
13. 9. 2002 0:46
> > Zamykani jen tak pro tve pohodli neni dobra technika. Pokud
> > uzivatel zacne zaznam editovat, je pred poslanim zmeny zapotrebi
> > zkontrolovat, zda nedoslo k jeho zmene.
>
> V praxi bez zamykani zaznamu uzivatel 5 minut tvori zmenu nejakeho zaznamu
a
> kdyz ho chce ulozit, tak se dozvi, ze ho mezitim nekdo zmenil a proto se
> jeho zmeny neulozi. Pote se mu ukaze aktualni stav zaznamu, ktery
samozrejme
> druhy uzivatel zmenil bud nepodstatne nebo chybne a muze 5 minut vyplnovat
> znovu a komentovat pri tom dusevni zdravi programatora.
v praxi by si mali uzivatelia prepisovat zaznamy len velmi vynimocne
a preto zatazovanie servera dlhotrvajucimi zamkami pocas editacie je
vyslovene neopodstatnene a poriadne neefektivne.
V pripade prepisania zaznamu nikde nie je povedane, ze uzivatel
musi udaje zadavat este raz. Je to vec aplikacneho programu
aby sa opytal uzivatela a umoznil mu predsa len tie zadane udaje
zapisat.
Erik
Odpovedá: Delphin
12. 9. 2002 19:01
> Zamykani jen tak pro tve pohodli neni dobra technika. Pokud
> uzivatel zacne zaznam editovat, je pred poslanim zmeny zapotrebi
> zkontrolovat, zda nedoslo k jeho zmene.
V praxi bez zamykani zaznamu uzivatel 5 minut tvori zmenu nejakeho zaznamu a
kdyz ho chce ulozit, tak se dozvi, ze ho mezitim nekdo zmenil a proto se
jeho zmeny neulozi. Pote se mu ukaze aktualni stav zaznamu, ktery samozrejme
druhy uzivatel zmenil bud nepodstatne nebo chybne a muze 5 minut vyplnovat
znovu a komentovat pri tom dusevni zdravi programatora.
Odpovedá: Marek Dostál
12. 9. 2002 17:35
Podévej se do dokumentace nebo nekam na optimistické a pesimistické zamykání.
Strucne: pesimistické: záznam se zamkne v okamziku, kdy vstoupis do rezimu
editace záznamu (napr.paradox), optimistické znamená, ze muze delat zmeny více
uzivatelu, ten první to ulozí a tem dalsím to vrátí chybu, kterou je potom
potreba osetrit. Zpusobu je více: nechat predeslé zmeny, nebo pokud není
konflikt na stejných polích záznamu, ulozit zmeny a tak ponechat i ty
predchozí, nebo záznam zcela nahradit. Vse zálezí na moznostech konkrétního SQL
serveru¨, aplikacního programu.
Zdravím, Marek Dostál
----- Original Message -----
From: "Zbysek Hlinka" <hlinka@hlinka.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, September 12, 2002 7:56 AM
Subject: Re: Lock nad IB recordom
> On 11 Sep 2002 at 21:04, Hlas wrote:
>
> > Nad paradoxom, ked som dal record do stavu Edit bol locknuty - ziadny
> > iny uzivatel nemohol tento zaznam editovat. Je nieco podobne mozne aj
> > nad IB zaznamom?
>
> Zamknout zaznam v IB neumim, anzto s IB nepracuji, ale chtel jsem
> rict, ze k zamykani zaznamu v databazi musi byt opravdu zavazny
> duvod. Zamykani jen tak pro tve pohodli neni dobra technika. Pokud
> uzivatel zacne zaznam editovat, je pred poslanim zmeny zapotrebi
> zkontrolovat, zda nedoslo k jeho zmene. A to se osetruje ulozenou
> procedurou, takze zadne zamykani neni nutne. Pokud nejaka baba zacne
> editovat, pak ji do toho zazvoni telefon, pak jde na zachod, obed, a
> kdovi kam jeste, mas na problemy zadelano, pokud je zaznam zamceny.
>
> S pozdravem
>
> Zbysek Hlinka
> E-mail: hlinka@hlinka.cz, localizator@localizator.com
> Phone: +420 603 551 282
>
>
>
Odpovedá: Zbysek Hlinka
13. 9. 2002 2:11
On 12 Sep 2002 at 11:06, Delphin wrote:
> > Zamykani jen tak pro tve pohodli neni dobra technika. Pokud
> > uzivatel zacne zaznam editovat, je pred poslanim zmeny zapotrebi
> > zkontrolovat, zda nedoslo k jeho zmene.
>
> V praxi bez zamykani zaznamu uzivatel 5 minut tvori zmenu nejakeho
> zaznamu a kdyz ho chce ulozit, tak se dozvi, ze ho mezitim nekdo
> zmenil a proto se jeho zmeny neulozi. Pote se mu ukaze aktualni stav
> zaznamu, ktery samozrejme druhy uzivatel zmenil bud nepodstatne nebo
> chybne a muze 5 minut vyplnovat znovu a komentovat pri tom dusevni
> zdravi programatora.
Jo kdyz to blbe naprogramujes tak jiste. To se dela tak, ze zapomenes
na db-aware komponenty (nad zivymi daty, nebo je pouzijes na nejakem
"odlozenem" datasetu, ktery neni spojen s databazi) a editujes si to
hezky v samostatnem okne v normalnich komponentach (rozhodne NE v
DBGridu, pokud to nevyzaduje zcela specialni a velmi dobre zduvodnena
situace). Pak editovana data seberes, posles je ulozene procedure.
Kdyz ti ulozena procedura vrati, ze nekdo jiny data uz zmenil, muzes
je v pohode zobrazit, a nechat na uzivateli, jak s tim nalozi dal. O
nic neprijdes, protoze nepouzivas db-aware komponenty nad zivymi
daty. Uzivatel bude spokojen, spravce databaze ti nebude nadavat, ze
mu tam nechavas viset zamky a ty budes spokojen, ze to radne funguje
a nehazi to zbytecne chyby.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: David Michal
13. 9. 2002 0:13
Zdravim,
Ja tady sleduji tuto debatu, zacinam premyslet zda je spravne, ze se o nic
podobneho nezajimam vubec a nechavam ciste na serveru co ulozi. Tzn. ktery
user ulozi zaznam pozdeji ten vyhral. Coz by snad nemel byt az tak spatny
pristup. Pokud tedy v aplikaci budou pristupova prava a dejme tomu s
tabulkou faktury bude moct pracovat pouze skupina useru k tomu vyclenena.
Pak by se snad nemelo stavat tak casto, ze dva budou editovat totez.
David
V praxi bez zamykani zaznamu uzivatel 5 minut tvori zmenu nejakeho zaznamu a
kdyz ho chce ulozit, tak se dozvi, ze ho mezitim nekdo zmenil a proto se
jeho zmeny neulozi. Pote se mu ukaze aktualni stav zaznamu, ktery samozrejme
druhy uzivatel zmenil bud nepodstatne nebo chybne a muze 5 minut vyplnovat
znovu a komentovat pri tom dusevni zdravi programatora.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/2002
Odpovedá: Kalhous Zdenek
13. 9. 2002 12:20
On 12 Sep 2002 at 9:40, Hlas wrote:
> Nad paradoxom, ked som dal record do stavu Edit bol locknuty - ziadny
> iny uzivatel nemohol tento zaznam editovat. Je nieco podobne mozne aj
> nad IB zaznamom?
Byla tady spousta odpovedi (i o necem jinem-o technice a strategii
programovani viceuzivatelskych databazovych aplikaci) vcetne
takovych, ze to nejde, ze se to nesmi, ze to je blbost a podobne.
Jde to a smi se to. Zaznam na ktery udelas update je zamknuty az
do ukonceni transakce. Takze kdyz chces zaznam jen zamknout
beze zmen, staci na zacatku transakce udelat neco jako
UPDATE ... SET ID=x WHERE ID=x
A jestli je to spatne naprogramovane, transakce zacne rano a skonci
vecer zatimco obsluha je u kadernika - to uz je prave o necem
jinem.
Odpovedá: Jan Sebelík
13. 9. 2002 16:51
> Odesílatel: David Michal <david.michal@www-bv.com>
> V praxi bez zamykani zaznamu uzivatel 5 minut tvori zmenu nejakeho zaznamu a
> kdyz ho chce ulozit, tak se dozvi, ze ho mezitim nekdo zmenil a proto se
> jeho zmeny neulozi. Pote se mu ukaze aktualni stav zaznamu, ktery samozrejme
> druhy uzivatel zmenil bud nepodstatne nebo chybne a muze 5 minut vyplnovat
> znovu a komentovat pri tom dusevni zdravi programatora.
Tak to snad neni.
Pokud dostanu (ja, ne uzivatel) chybu pri ukladani, data jeste nejsou ztracena.
Pak zalezi na mne (programatorovi) jak s tim nalozim, co reknu uzivateli, jake
mu dam moznosti reagovat.
Jak uz jsem psal, (podle me) dost pekne to resi TClientDataSet a ApplyUpdates.
V pripade konfliktu vrati starou (nactenou), novou (opravenou) a aktualni (co
je na serveru) hodnotu a da mi vybrat, co s tim chci delat. To pro kazdy field
zvlast.
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================
Odpovedá: Zbysek Hlinka
13. 9. 2002 13:48
On 12 Sep 2002 at 20:20, David Michal wrote:
> Zdravim,
> Ja tady sleduji tuto debatu, zacinam premyslet zda je spravne, ze se o
> nic podobneho nezajimam vubec a nechavam ciste na serveru co ulozi.
> Tzn. ktery user ulozi zaznam pozdeji ten vyhral. Coz by snad nemel byt
> az tak spatny pristup. Pokud tedy v aplikaci budou pristupova prava a
> dejme tomu s tabulkou faktury bude moct pracovat pouze skupina useru k
> tomu vyclenena. Pak by se snad nemelo stavat tak casto, ze dva budou
> editovat totez. David
No, to zalezi na typu ulohy. Ukazu na prikladu, kde muze byt
takovyhle pristup (ale i ten se zamky) fatalni chybou. Mejme cenik a
predpokladejme, ze nekolik pracovniku ma na starosti kazdy svou cast
ceniku. Nekdo bude editovat jednu polozku ve sve casti ceniku.
Mezitim se sef rozhodne, ze napric celym cenikem udela slevu, nebo se
zmeni sazba DPH nebo cokoliv podobneho. Neni dost dobre mozne, aby
sef vyzval vsechny pracovniky, ze chce delat zmenu, at ukonci svou
praci, pak udela zmenu, a pak zase vsechny obesle, ze mohou pracovat.
Jak zamek, tak "posledni bere vse" skonci chybou v ceniku.
Spravny postup je tento: Sef provede zmenu. Pracovnik, ktery mezitim
neco edituje, chce zaznam ulozit. SP vsak zjistit zmenu, tak ohlasi,
kdo zmenu provedl, a kde. Pracovnik pak ma moznost spravne rozhodnout
o dalsim postupu a chyba nemusi vzniknout.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Pavel Cisar
13. 9. 2002 10:50
Haj hou!
On 12 Sep 2002 at 9:24, Jan Sebelík wrote:
> Mozna me nekdo opravi, ale pokud se nemylim, tak to nejde.
Ono to jde simulovat pomoci "falesneho update", tedy provedenim zmeny,
ktera ulozi ta sama data (data jsou stejna, ale pro server je to zmena
jako kazda jina). Tim dojde k zablokovani radku pro ostatni transakce
dokud neni proveden commit nebo rollback. Ale rozhodne bych to nedelal 
S pozdravem
Pavel Cisar
Mobil: 0724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Delphin
13. 9. 2002 17:18
> Pracovnik pak ma moznost spravne rozhodnout
> o dalsim postupu a chyba nemusi vzniknout.
Teoreticky je to 100% funkcni, ale v realnem provozu se pracovnik s dost
velkou pravdepodobnosti rozhodne spatne a chyba vznikne ...
Odpovedá: Zbysek Hlinka
13. 9. 2002 17:39
On 13 Sep 2002 at 16:38, Delphin wrote:
> > Pracovnik pak ma moznost spravne rozhodnout
> > o dalsim postupu a chyba nemusi vzniknout.
>
> Teoreticky je to 100% funkcni, ale v realnem provozu se pracovnik s
> dost velkou pravdepodobnosti rozhodne spatne a chyba vznikne ...
Porad ale vznikne mene chyb, nez pri pouziti zamku nebo prepisovani
natvrdo podle posledniho. Zejmena, kdyz je kazda zmena protokolovana,
kdo ji provedl. 
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Ludek ZITA
17. 9. 2002 16:03
----- Original Message -----
From: "Delphin" <delphin@post.cz>
> > Pracovnik pak ma moznost spravne rozhodnout
> > o dalsim postupu a chyba nemusi vzniknout.
>
> Teoreticky je to 100% funkcni, ale v realnem provozu se pracovnik s dost
> velkou pravdepodobnosti rozhodne spatne a chyba vznikne ...
>
Ahoj.
Dovoliim si s Tebo vyrazne nesouhlasit. Zbyskovo reseni jedine skutecne resi
chyby zpusobene soucasnou praci na siti.
Vsechny predesle delaji to, ze nektery z pracovniku odchazi domu s pocitem
ze cenu spravne upravil z hodnoty A na hodnotu B a nevi ze mu ji pod rukou
nekdo zmenil.
Zbyskovo reseni uzivatele informuje a dava mu moznost reagovat.
Nerozumim tomu proc by se obchodnik ktery otevre kartu zbozi a hodla zmenit
cenu z 590 na 490 a pri ulozeni mu program zahlasi ze ji prave vedouci
zmenil z 590 na 390 (prtotze vsechno zlevnil davkove o 200) nedokazal
spravne rozhodnout. Minimalne zvedne telefon a nejak se domluvi se sefem.
Opravdu nevim co je na tom tak spatneho ze by tohle vedlo lidi k chybam.
Horsi by bylo, kdyby v pripade neosetreni tohoto stavu vedouci mel pocit ze
ceny zmenil a pritom by netusil ze se zmena neprovedla a ani obchodnik by
nevedel ze vlezl sefovi do zeli. Skoncilo by to nakonec jeho sprdunkem,
protoze nekde v logu by bylo ze cenu zmenil on a uz tezko by se dohledavalo,
ze on vlastne nemenil cenu smerem nahoru ale dolu a trefil se do sefovy
davky.
Problem je samozrejme s programatorovou lenosti, protoze tohle da mnohem vic
prace nez treba nechat optimisticky zamek.
Ludek